@jenkins-droid test this please

@jenkins-droid please test this

FYI, I created a PR to place operations on devices by using device attribute #2510. If we use that, we don't need to pass the cost model to every legality check function.

Since we are going to add different control on the conversion, I suggest that we clear up the program structure first.

1. For a conversion, define an analysis set. Currently, there is only DimAnalysis.

2. Decide which op will be converted with the current AddDynamicallyLegalOpFor<>(op, analysis_set, flags). Basically to implement addDynamicallLegal

3. In the AddDynamicallyLegalOpFor (Actually target->addDynamicallyLegalOp<OP_TYPE>), we should unify the code for different Op and a common part as much as possible.
   First check whether it is legal for the conversion. This is the isSuitableForZDNN(op). If it returns false, this Op has to be legal. This Op can not be converted. I suggest change the name isSuitableForZDNN to isLegalForZDNN.
   Then use the analysis results (traverse the analysis set) to decide whether we want to convert the op. The analysis result can be generated with a global view, or from file or command line. Drawback is the possible overhead on Ops eliminated by other standard.
   Finally, check locally of the current Op to make decision.

4. The rewriting rules decide ONLY HOW to convert, assuming that Ops have been checked and decided.

@AlexandreEichenberger @tungld Should we restructure the code before we add new code?

@chentong319 fyi #2510

@tong fyi #2510

i am not the tong you are looking for.

FYI, I created a PR to place operations on devices by using device attribute #2510. If we use that, we don't need to pass the cost model to every legality check function.

Sure, this PR can refactor the benefits as a separate function that can be separate from the legality check.

I suggest that we clear up the program structure first.

You are making excellent points @chentong319, I will transform the code to separate benefit from validity (it was kind of separate already if we disable the benefit flag, but it is indeed better to have a stronger/clearer separation.

@AlexandreEichenberger looks like this patch is replaced by #2534 that was landed.